Security audit | Tarantool

Security audit

This document will help you audit the security of a Tarantool cluster. It explains certain security aspects, their rationale, and the ways to check them. For details on how to configure Tarantool Enterprise Edition and its infrastructure for each aspect, refer to the security hardening guide.

Tarantool uses the iproto binary protocol for replicating data between instances and also in the connector libraries.

Since version 2.10.0, the Enterprise Edition has the built-in support for using SSL to encrypt the client-server communications over binary connections. For details on enabling SSL encryption, see the Traffic encryption section of this document.

In case the built-in encryption is not enabled, we recommend using VPN to secure data exchange between data centers.

When a Tarantool cluster does not use iproto for external requests, connections to the iproto ports should be allowed only between Tarantool instances.

For more details on configuring ports for iproto, see the advertise_uri section in the Cartridge documentation.

A Tarantool instance can accept HTTP connections from external services or access the administrative web UI. All such connections must go through an HTTPS-providing web server, running on the same host, such as nginx. This requirement is for both virtual and physical hosts. Running HTTP traffic through a few separate hosts with HTTPS termination is not sufficiently secure.

Tarantool accepts HTTP connections on a specific port, configured with http_port: <number> value (see configuring Cartridge instances). It must be only available on the same host for nginx to connect to it.

Check that the configured HTTP port is closed and that the HTTPS port (443 by default) is open.

The console module provides a way to connect to a running instance and run custom Lua code. This can be useful for development and administration. The following code examples open connections on a TCP port and on a UNIX socket.

console.listen(<port number>)
console.listen('/var/lib/tarantool/socket_name.sock')

Opening an administrative console through a TCP port is always unsafe. Check that there are no calls like console.listen(<port_number>) in the code.

Connecting through a socket requires having the write permission on the /var/lib/tarantool directory. Check that write permission to this directory is limited to the tarantool user.

Connecting to the instance with tt connect or tarantoolctl connect without user credentials (under the guest user) must be disabled.

There are two ways to check this vulnerability:

  • Check that the source code doesn’t grant access to the guest user. The corresponding code can look like this:

    box.schema.user.grant('guest',
        'read,write',
        'universe',
        nil, { if_not_exists = true }
    )
    

    Besides searching for the whole code pattern, search for any entries of 'universe'.

  • Try connecting with tt connect to each Tarantool node.

For more details, refer to the documentation on access control.

Using the web interface must require logging in with a username and password. See more details in the documentation on configuring web interface authorization.

All Tarantool instances should be running under the tarantool user.

The tarantool user must be a non-privileged user without the sudo permission. Also, it must not have a password set to prevent logging in via SSH or su.

In order to have a reliable backup, a Tarantool instance must keep two or more latest snapshots. This should be checked on each Tarantool instance.

The snapshot_count value determines the number of kept snapshots. Configuration values are primarily set in the configuration files but can be overridden with environment variables and command-line arguments. So, it’s best to check both the values in the configuration files and the actual values using the console:

tarantool> box.cfg.checkpoint_count
---
- 2

Tarantool records all incoming data in the write-ahead log (WAL). The WAL must be enabled to ensure that data will be recovered in case of a possible instance restart.

Secure values of wal_mode are write and fsync:

tarantool> box.cfg.wal_mode
---
- write

An exclusion from this requirement is when the instance is processing data, which can be freely rejected. For example, when Tarantool is used for caching. Then WAL can be disabled to reduce i/o load.

For more details, see the wal_mode reference.

The logging level should be set to 5 (INFO), 6 (VERBOSE), or 7 (DEBUG). Application logs will then have enough information to research a possible security breach.

tarantool> box.cfg.log_level
---
- 5

For a full list of logging levels, see the log_level reference.

Tarantool should use journald for logging.

Found what you were looking for?
Feedback